HTTP (Hypertext Transfer Protocol) used as the standard in transferring a page file written in a page description language, such as HTML (Hypertext Markup Language), is a protocol that closes transactions for each request (processing request) from a client system. In other words, because there is no concept of a continued session, it cannot handle a series of requests by associating one with another. In the case of a simple request asking a server to distribute news, provide products information, etc., the processing may be completed by merely sending the contents (page file) back to the client that originated the request. However, in order to achieve a shopping cart function in a shopping site or a function of customizing a Web page to individual users, there is a need for user (viewer) tracking management during manipulations over a plurality of pages. In other words, it is necessary to introduce a concept of session management by tracking a user in some way.
An IP (Internet Protocol) address, for example, may be used in identifying the client that originated a request. However, nowadays it is general to use address converting means, such as NAT (Network Address Translator), a proxy server, and a gateway, and it is doubtful whether the client at the IP address is really the client that originated the request.
Hence, a session managing method using cookies is generally adopted. Cookies are information files for recording information sent from a Web site to a client's end into a hard disc or the like in the client system. At the beginning of a session, the Web site issues identification information, such as a session ID, to the client, and the browser at the client's end records the identification information into a cookie. When the client accesses again the Web page that issued the cookie, the information saved in the cookie is sent to the Web site. This enables the Web site (server's end) to implement session management or customization to individual users by using the cookie information.
However, in order to use cookies, the client system on which the browser is run needs to have a sufficient record region (hardware resource), such as a personal computer. Thus, for example, a portable terminal, such as a cellular phone, having an insufficient memory region may not be able to use cookies. Also, some browsers are not provided with a function for cookies. Further, the user may switch off cookies. More specifically, a server sends information to cookies without the user's knowledge or permission and uses this information. Hence, some users do not wish to use cookies due to privacy and security concerns. Thus, the user may inhibit the use of cookies by the user-defined browser.
When cookies are unavailable, it is impossible to make a page design at a Web site based on an assumption that cookies are available. Thus, there is need for a page design based on the assumption that cookies are unavailable. The following are methods known as a technique for session management under HTTP without using cookies.
One is a method for implementing session management at the Web application level. An example would be a method for passing on session information as a CGI (Common Gateway Interface) parameter each time the user moves from one page to another. To be more specific, a session ID is generated at the login, and this session ID is redirected to a first page as a parameter. The CGI receives the session ID passed as a parameter, and a program at the server's end connected by the CGI dynamically creates a page including a hyperlink having embedded the session ID. Because the hyperlink included in the page thus created includes the session ID as the CGI parameter, the session ID is passed on to another page as the user moves to another link (hyperlink choosing operation). In this manner, a unique session ID is held along a series of link-to-link movements, which makes it possible to implement the user tracking management by referring to the session ID whenever necessary.
A second method incorporates passing a session ID as a basic function of the Web server. To be more specific, it is a method for appending identification information (session ID) at the end of a URL (Uniform Resource Locator) of a hyperlink and automatically extracting the identification information at the Web server. Web servers, such as Apache Web servers, are designed so that a Web page is constructed by using a Java (trademark of Sun Microsystems) servelet. These servers are furnished with a function of embedding a session ID at the end of the URL of a link destination and extracting the session ID from the URL when accessing a page, that is, a URL rewriting function. By using the URL rewriting function, it is possible to pass on the session ID from one linked page to another in the same manner as the first method, and a Web application can be run without concern for the passing of the ID session.
As described above, it is possible to implement session management by adopting either of the methods even in an environment where cookies are unavailable. However, these existing methods have problems as follows.
First, both methods need a page design made on the proposition that a technique furnished with a function achieving these methods is adapted. For example, in the case of the first method, it is necessary to design a page so that a CGI parameter can be passed on. In the case of the second method, the use of JSP (Jave Server Pages) is a proposition because the URL of a link destination has to return a value of an Encode URL function. When a Web site is already constructed with static pages, these pages have to be reconstructed on the proposition that a technique achieving either method is adapted, which increases the burden of a page designer.
Second, both methods need to create a page dynamically at the server's end in order to pass a session ID to a linked page. To be more specific, a dynamic page has to be created for each request even if a page does not need the processing for individual users, such as a simple page like a table-of-contents page and a products introduction page, that is, a page that can serve its purpose satisfactorily as being a static page. Handling a dynamic page has disadvantages as follows. That is, because a dynamic page is created for each request, a load on the page-creating server is increased. Also, because the session ID is included in each link in the page, the page size is increased. For example, given 30 bytes as the size of the session ID, then, if there are 10 links in one page, the page size is increased by 300 bytes, and if there are 100 links, the page size is increased by 3000 bytes. If a user bears a communications charge for a page download, such an increase in the page size adversely affects the charging status of the user, and it could hamper convenience of users.
Third, when a user terminal is, for example, an i-mode cellular phone, neither a session ID is sent in an unofficial site, nor is a cookie available. Hence, in order to implement session management with a terminal of this kind, the first or second method needs to be adopted. However, because an i-mode terminal has to use compact HTML, which is a subset of HTML, a page size is too small to use the existing method with ease, thereby presenting a high hurdle. Hence, there is a need for a simpler session managing method.
The invention is addressed to provide an extremely simple session managing method, a session managing method capable of using a static page, a session managing method for minimizing burdens in reconstructing an already constructed Web site, a session managing method for reducing a load to the server, a session managing method that does not increase a page size of a Web page, and a session managing method that can be readily achieved in a function-limited environment, such as an i-mode portable terminal.